For Internet of things (IoT) deployments, there can be millions or billions of IoT devices that send data towards a service capability server (SCS) or an application server (AS). For example, IoT devices, such as sensors, can initiate a data transfer based on a particular time or event. When multiple IoT devices transmit at the same time or in response to the same event, a traffic storm at the SCS or AS that receives the traffic can occur. A traffic storm at an SCS or AS can lead to temporary unavailability of the SCS or AS. In another example, a traffic storm can overwhelm the resources of an application programming interface (API) node of an SCEF that sends notification messages to SCSs or ASs. If the API interface to an SCS or AS becomes overwhelmed with traffic, the service provided by the SCS or AS is likewise unavailable.
In another example, a single misbehaving IoT device may lead to traffic storms at an SCS, AS or API interface. For example, if an IoT device is either intentionally or unintentionally malfunctioning, such a device can lead to a traffic storm in an operator's network. The malfunctioning IoT device may repeatedly send messages to the API, the SCS, or the AS, which can lead to unavailability of services provided by such nodes.
In order to protect against traffic storms, overload control can be provided at network elements, such as the eNode B, mobility management entity (MME), serving general packet radio service (GPRS) support node (SGSN), etc. However, providing flow control at these nodes can be inefficient due to their distributed location in the network. For example, implementing a flow control solution at every eNode B in the network may be cost prohibitive due to the number of eNode Bs in the network. Also, even if a network operator applies overload control at individual network components, the SCEF may be receiving data from such multiple nodes e.g., MME/SGSN. Thus upstream SCS/AS servers could still be adversely affected.
Another problem that exists in some flow control solutions is the inability to provide fine grained flow control. For example, some traffic storms may only affect a single SCS or AS, and it may be desirable to implement flow control specific to that SCS or AS, given its capacity. Within an SCS or AS, it may also be desirable to provide high priority service to particular users, such as emergency personnel. Flow control solutions that are not specific to an SCS or AS may not allow for SCS or AS capacity specific throttling of messages or selective prioritization of messages associated with high priority users.
In light of these and other difficulties, there exists a need for methods, systems, and computer readable media for overload and flow control at an SCEF.